MSF for Agile Software Development

Principles

The Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.   For more information see the link in the "See Also" section on this page.

Focus on Quality

Software quality is a mindset.  To achieve quality is the job and focus of every member of the team.  Teams should take a pragmatic approach to quality assurance; that is, do what works even if it is low tech!  Teams that make a commitment to quality catch problems early in the software development cycle when they cost the least. 

Embrace Change

Traditional software development teams define interaction with the business owners through contracts.  This idea must be smashed!  Scrum teams embrace change.  Backlog items within a sprint can be easily replaced with other backlog items of equal effort.  If a backlog item has been started and needs to be replaced or if new backlog items will significantly change the sprint schedule, the team comes together with the business users to decided the course of action to take.   Remember there are two finite resources for the sprint, time and resources.  Trust must be built with the business users so that a true team environment with the needed give and take can be created.  

Coaching, not Managing

Traditional development team have one or more managers who make all of the decisions for the team.  Often these managers have little or no background in development technology.  The scrum master's sole job is to make the team more effective.  To do this, he or she removes any road blocks that the team faces.  While the goal is self managing teams,  we are practical.  Teams have different skill and experience levels and thus need different levels of direction from the scrum master.  Do what works best for the team, but work towards self managing teams.

Communicate, Communicate, Communicate... and then Communicate some more!

One of the main reasons that projects fail is a lack of communication.  Communication barriers make teams ineffective.  Teams are redefined to include the business owners as well as the developers, testers and business analysts.  Teams are located as close together as possible or use technology that enables instant communication.  Visibility into the development process is encouraged and facilitated by all members of the team.

 

 

 

 


   

© 2007 TFS MVP Community

MVP Logo

Version 2.1